Applicant : Lance W. Russell 

Serial No. : 09/895,235 

Filed : June 28, 2001 

Page : 9 of 37 



Attorney's Docket No.: 10003532-1 
Amendment dated May 4 , 2009 
Reply to Cffice action dated Feb. 5 , 2009 



Remarks 



Status of claimg 



Claims 1-9, 11-25, and 27-30 are pending. 

II. Claimreiections under 35 U.S. C. g 101 

The Examiner has rejected claims 1, 2-8, 19, 21-25, and 27-30 under 35 U.S.C. § 101 
as being directed to non-statutory subject matter (i.e., software). 

Independent system claim 1 has been amended and defines patent-efigible subject 
matter because it recites structural elements (e.g., amemory and a processor). Each of claims 
2-8, 21-25, 27, and 28 depends from claim 1 and therefore is directed to patent -ehgible 
subject matter for at least the same reasons as claim 1. 

Independent system claim 5 has been amended and defines patent-efigible subject 
matter because it recites structural elements (e.g., first and second network nodes). 

Dependent method claims 19 and 29 have been amended and are directed to patent- 
ehgible subject matter because they are tied to particular machines (i.e., respective network 
nodes). 

III. Claim objection 

The Examiner has objected to claim 11 "because the term 'computer readable 
medium' is not addressed in appficant's specification." Claim 1 1 , however, does not receive 
the term "computer-readable medium." 

IV. Prior art claim rei ections 

A. Rejection of claims 1-4, 6-9, 11-14, 16-25, and 30 under 35 U.S.C. § 102(e) 
over Turdi 

The Examiner has rejected claims M, 6-9, 1 1-14, 16-25, and 30 under 35 U.S.C § 
102(e) over Turek (U.S. 6,460,070). 
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1. Applicable standards for sustaining a rejection under 35 U.S.C. g 102(6) 

The relevant part of 35 U.S.C. § 102(e) states that apeison shall be entitled to an 
invention, unless - "the invention was described in ~ (1) an application for patent published 
under section 122(b), by another filed in the United States before the invention by the 
applicant for patent. . ." Anticipation under 35 U.S.C. § 102(e) requires that each and every 
element of the claimed invention be present, either expressly or inherently, in a single prior 
art reference. EMI Group N. Am., hic, v. Cypress Semiconductor Corp. . 268 F.3d 1342. 
1350 (Fed. Cir. 2001). Anticipation must be proved by substantial evidence, hire Crish. 393 
F.3d 1253, 73 USPQ2d 1364 (Fed. Cir. 2004). 

2. Independent claim 1 
a. Introduction 

Independent claim 1 has been amended and now redtes: 

1 . A system for managing a plmahty of distributed 
nodes of a network, comprising: 



a memory storing computer-readable instructions; and 

a processor coupled to the memory, operable to execute 
the instructions, and based at least in part on the execution of 
the instructions opemble to perform operations comprising 
executing a network management module that causes the 
processor to launch migratory recovery modules into the 
network to monitor status of each of the network nodes; 

wherein each of the recovery modules is configured to: 
cause any given one of the network nodes to migrate the 
network node from the given network node to another one of 
the network nodes; cause any given one of the network nodes 
to determine a respective status of the given network node; and 
cause any given one of the network nodes to initiate a recovery 
process on the given network node in response to a 
determination that the given network node has one or more 
failed node processes; 

wherein in the executing the network management 
module causes the processor to launch the recovery modules in 
order to determine the status of each of the network nodes; and 

wherein in the executing the network management 
module causes the processor to monitor transmissions that are 
received from the recovery modules executing on respective 
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ones of the network nodes in order to provide periodic 
monitoring of the status of each of the network nodes. 

As explained in detail below, the rejection of independent claim 1 under 35 U.S.C. § 
102(e) over Turek should be withdrawn because Turek neither expressly nor inherently 
discloses each and every element of the invention defined by the claim. 

b. The Examiner' s position 

In support of the rejection of independent claim 1 , the Examiner has stated that (see § 
19, page 8 of the Office action dated February 5, 2009; emphasis added): 



As per claims 1 , 11, 19 & 20 Turek disclosed a method for 
managing a plurality of distributed nodes of a network, 
comprising: a network management module that launches 
migratory recovery modules into the network to monitor status 
of each of the network nodes; wherein each of the recovery 
modules is configured to migrate from one network to another, 
determine a respective status of each of the network nodes to 
which it has migrated, and initiate a recovery process on Mled 
ones of the network nodes.(col.3, fines 48-64, col.l, fines 59- 
62, 65-67, col.2, lines 22-26, col.2, lines 1-3, col.2, fines 22-26 
& col. 5, fines 32-60), having one or more failed node 
processes, the recovery modules determine the status of each of 
the network nodes, and the network management module 
monitors tiansmissions that are received from the recovery 
modules to provide periodic monitoring of the status of the 
network nodes (col.7, fines 58-67 & col.8, fines 1-9) after 
initiating the recovery process, migrating from the current node 
to a successive one of the network node (col.5, fines 32-60, 
col.7, lines 58-67 & col.8, fines 1-65), and the network 
management module monitors transmissions that are received 
from the recovery modules to provide periodic monitoring of 
the status of each of the network nodes (col.7, lines 58-67, col. 
8, lines 1-9 & col.8, fines 39-58). 
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C. 



A ppellant's rebuttal: Turek does not disclose each and every element of claim 
i 



i. 



Turek does not disclose a network management module that causes the 
processor to launch migratory recovery modules into the network to monitor 
status of each of the network nodes 



Turek does not disclose or suggest a network management module that causes the 
processor to launch migratory recovery modules into the network to monitor status of each of 
the network nodes. 

As explained in detail below, Turek' s system does not launch migratory recovery 
modules into a network to monitor status of each of the network nodes, wherein the recovery 
modules determine the status of each of the network nodes and the network management 
module monitors transmissions that are received from the recovery modules to provide 
periodic monitoring of each of the network nodes. 

(1) Turek' s disclosure 

In accordance with Turek' s disclosure, the mobile software agents are deployed by 
the dispatch mechanism 15 in the management server 14 only in response to either a report of 
a "network 'feult', alarm or other such trigger" (col. 7, hnes 3-4) or a "request for 
maintenance in some non-specified area of the network" (col. 7, line 7). The dispatch 
mechanism 15 deploys a selected one of the software agents to the particular location of a 
fault or a particular area of a network where the feult is likely to have occurred (see, e.g., col. 
7, lines 1-57). If the initial given node location does not contain the specific feult for which 
the software agent was deployed, the software agent identifies "a subset of nodes (associated 
with the given node) that remain candidates for locating the erroi" (col. 8, lines 31-32). Once 
the particular feult is located and diagnosed, the software agent attempts to fix the problem 
(see col. 9, lines 21-22). "If unable to effect repairs, the agent wih, at a minimum, report 
back with the diagnosis to auser interfece of the dispatch mechanism" (col. 9, lines 28-30). 
Turek does not teach or suggest anything that that would have led one skilled in the art at the 
time the invention was made to beheve that the software agent migrates to any other nodes 
after attempting to "effect repairs" and reporting back with the diagnosis. To the contrary, in 
accordance with Turek' s teachings, each of the mobile software agents is deployed to 
diagnose and, if possible correct, only one particular network feult (see, e.g., col. 5, hnes 43- 
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60). Therefore, there is no apparent need for any of Turek's software agents to migrate from 
the node that contains the particular network fault that the software agent was deployed to 
diagnose and correct. 

Thus, one skilled in the art at the time the invention was made would not have had 
any basis for believing that Turek' s system launches migratory recovery modules into a 
network to monitor status of each of the network nodes, as recited in claim 1 . In accordance 
with its ordinary and accustomed meaning, the verb "monitoi" means "to watch, keep track 
of, or check usu. for a special purpose" (Meniam- Webster's Cohegiate Dictionary, Tenth 
Edition (1995). The dispatch mechanism 15 does not launch migratory recovery modules 
into the network to monitor status of each of the network nodes. Instead, the dispatch 
mechanism 15 deploys the software agents only after a network feult aheady has been 
determined by the management server 14 (see, e.g., col. 7, hnes 34) or after receiving a 
"request for maintenance in some non-specified area of the network" (col. 7, fine 7), and the 
dispatched agents cease migrating after reaching their respective target nodes. 

In addition, one sMlled in the art at the time the invention was made would not have 
had any basis for beheving that Turek' s software agents determine the status of each of the 
nodes of a network. To the contrary, based on Turek' s teaching, such a person would have 
recognized that the software agents are designed to recursively narrow the search for the 
particular network nodes for which they were respectively deployed and, after arriving at the 
target network nodes, the software agents attempt to effect repaii^ and report back diagnoses; 
the dispatched agents cease migrating after reaching their respective target nodes. That is, the 
software agents are not configured to determine the status of each of the network nodes, as 
recited in claim 1 . Moreover, Turek only teaches that each of the software agents is 
configured to determine whether a particular event originated from a node (see col. 2, fines 
49-53). Turek does not teach that these agents are configured to determine the status of their 
respective taiget nodes. Consequently, the dispatch mechanism 15 is not configured to 
provide periodic monitoring of the status of each of the network nodes, as recited in claim 1. 

(2) The cited sections of Turek's disclosure do not support the Examiner' s 



The Examiner has pointed to col. 3, fines 48-64, col.l, lines 59-62, 65-67, col.2, lines 
22-26, col.2, fines 1-3, col.2, fines 22-26 & col.5, lines 32-60 in support of the position that 
Turek discloses "a network management module that launches migratory recovery modules 



position 
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into the network to monitor status of each of the network nodes; wherein each of the recovery 
modules is configured to migrate from one network node to another, determine a respective 
status of each of the network nodes to which it has migrated, and initiate a recovery process 
on ones of the network nodes having one or more failed node processes, the recovery 
modules determine the status of each of the network nodes" (see § 7 on page 4 of the Office 
action dated September 18, 2008). As explained in detail below, however, the cited sections 
of Turek' s disclosure, however, do not support the Examiner's characterization of Turek's 



Col.3. lines 48-64: 

Col.3, lines 48-64 recites: 

Referring now to FIG. 1, the invention is preferably 
implemented in a large distributed computer environment 10 
comprising up to thousands of "nodes." The nodes will 
typically be geogr^hically dispeised and the overall 
environment is "managed" in a distributed manner. Preferably, 
the managed environment (ME) is logically broken down into a 
series of loosely-connected managed regions (MR) 12, each 
with its own management server 14 for managing local 
resources with the MR. The network typically will include 
other servers (not shown) for carrying out other distributed 
network functions. These include name servers, security 
servers, file servers, threads servers, time servers and the hke. 
Multiple serveiB 14 coordinate activities across the enterprise 
and permit remote site management and operation. Each server 
14 serves a number of gateway machines 16, each of which in 
turn support a plurahty of endpoints 18. The server 14 
coordinates aU activity within the MR using a terminal node 
manager 20. 

This disclosure does not teach or suggest anything about launching migratory 
recovery modules, much less anything about "a network management module that launches 
migratory recovery modules into the network to monitor status of each of the network nodes; 
wherein each of the recovery modules is configured to migrate from one network node to 
another, determine a respective status of each of the network nodes to which it has migrated, 
and initiate a recovery process on ones of the network nodes having one or more failed node 
processes, the recovery modules determine the status of each of the network nodes." 



teachings. 
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Col. 1. lines 59-62, 65-67: 



Col. 1, Unes 59-62, 65-67 recites: 



It would be a significant advantage to provide some automatic 
means of diagnosing and correcting network problems in this 
type of computer environment. The present invention addresses 
this important problem. 

It is aprLmary object of this invention to automatically 
diagnose feults or other events that occur in a large, distributed 
computer network. 



This disclosure does not teach or suggest anything about launching migratory 
recovery modules, much less anything about "a network management module that launches 
migratory recovery modules into the network to monitor status of each of the network nodes; 
wherein each of the recovery modules is configured to migrate from one network node to 
another, determine a respective status of each of the network nodes to which it has migrated, 
and initiate a recovery process on ones of the network nodes having one or more failed node 
processes, the recovery modules detemiine the status of each of the network nodes." 

It is noted that diagnosing and correcting network problems does not constitute 
monitoring the status of each of nodes in a network. 

Col. 2. fines 1-3: 

Col. 2, lines 1-3 recites that "It is another primary object of this invention to deploy a 
software "agent" into a distributed computer network environment to diagnose and, if 
possible, correct a fault." 

This disclosure does not teach or suggest "a network management module that 
launches migratory recovery modules into the network to monitor status of each of the 
network nodes; wherein each of the recovery modules is configured to migrate from one 
network node to another, determine a respective status of each of the network nodes to which 
it has migrated, and initiate a recovery process on ones of the network nodes having one or 
more failed node processes, the recovery modules determine the status of each of the network 
nodes." 
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It is noted that diagnosing and correcting network problems does not constitute 
monitoring the status of each of nodes in a network. 

Col. Z hnes 22-26: 

Col. 2, hnes 22-26 redtes: 

Yet another object of the present invention is to coUect 
information about network conditions as mobile software 
agents are dispatched and migrated throughout a large 
computer network to correct network faults, wherein such 
information is then useful in diagnosing new faults. 

This disclosure does not teach or suggest "a network management module that 
launches migratory recovery modules into the network to monitor status of each of the 
network nodes; wherein each of the recovery modules is configured to migrate from one 
network node to another, determine a respective status of each of the network nodes to which 
it has migrated, and initiate a recovery process on ones of the network nodes having one or 
more failed node processes, the recovery modules determine the status of each of the network 



It is noted that collecting from mobile software agents information that is useful in 
diagnosing new faults does not constitute monitoring the status of each of nodes in a network. 

Col. 5. hnes 32-60 

Col. 5, hnes 32-60 redtes: 



A preferred embodiment of the present invention is 
implemented in the enterprise environment illustrated above. In 
this embodiment, a set of "software agents" are available at a 
central location (e.g., manager 14) or at a pluraHty of locations 
(e.g., the gateways 16) in the o network where network errors 
are reported. The software agents are "mobile" in the sense that 
the agents are dispatched (as wiU be described below) from a 
dispatch mechanism and then migrate throughout the network 
environment. Generally, the mobile software agents traverse 
the network to diagnose and, if possible, to correct a network 
fault. 

Thus, when a network error or "feult" is reported whose cause 
and location are not apparent or readily ascertainable, an 
appropriate agent is identified and dispatched to determine this 



nodes." 
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infonnation. Preferably, the agent is dispatched to the actual 
node in the network at which the fault condition occui^. As will 
be seen, the particular error, as weh as other associated events, 
generally provide a "clue" or clues regarding the network 
location to which the agent should be sent, as weh as the type 
of agent to send. If the agent does not find the fault at the initial 
location to be examined, the agent then migrates through the 
network to locate the error. The agent preferably chooses its 
path through the network based on the information received at 
the dispatching location, as well as information gleaned from 
each examined location. As will be seen, the particular "path" 
typicahy varies as the software agent migrates through the 
network because information gleaned from a particular node 
may redirect the agent in some given manner. 

This disclosure does not teach or suggest "a network management module that 
launches migratory recovery modules into the network to monitor status of each of the 
network nodes; wherein each of the recovery modules is configured to migrate from one 
network node to another, determine a respective status of each of the network nodes to which 
it has migrated, and initiate a recovery process on ones of the network nodes having one or 
more failed node processes, the recovery modules determine the status of each of the network 
nodes." Instead, the cited disclosure merely teaches that each of the mobile software agents 
is deployed to diagnose and, if possible correct, a particular network fault (see, e.g., col. 5, 
lines 43-60). 

It is noted that diagnosing and correcting network problems does not constitute 
monitoring the status of each of nodes in a network. 

(3) Conclusion 

For the reasons explained above, Turek does not expressly nor inherently disclose a 
network management module that launches migratory recovery modules into the network to 
monitor status of each of the network nodes. 

ii. Turek also does not disclose a network management module that "monitors 

transmissions that are received from the recovery modules to provide periodic 
monitoring of the status of each of the network nodes" 



In the Office action dated March 20, 2008, the Examiner had acknowledged that 
"Turek did not explicitly disclose the recovery module (software agents) periodically sending 
network node status" (see page 6, lines 8-9, of the Office action dated March 20, 2008). Yet, 
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now in the Office action dated February 5, 2009, the Examiner has taken the position that 
Turek discloses "the network management module monitors transmissions that are received 
from the recovery modules to provide periodic monitoring of the status of each of the 
network nodes" in col. 7, fines 58-67 and col. 8, fines 1-9 (see § 19 on page 8 of the Office 
action). As explained in detail below, however, the cited sections of Turek' s disclosure, 
however, do not support the Examiner's characterization of Turek' s teachings. 

Col.7, fines 58-67 - col. 8. fines 1-9: 

Col.7, fines 58-67 - col. 8, fines 1-9 recites (emphasis added): 

The method continues at step 46 with the software agent being 
deployed into the network. At step 48, the software agent 
migrates though the network. A test is then done at step 50 to 
determine whether the software agent has located the fault . If 
the outcome of the test at step 50 is negative, the routine cycles. 
If however, the outcome of the test at step 50 indicates that the 
software agent has arrived at the fault location , the routine 
continues at step 52. At this step, software agent (either alone, 
or together with some fimctionafity provided by the runtime 
engine already resident on the node) diagnoses the fault. At step 
54, a test is done to determine whether the software agent 
(either alone, or together with some fimctionafity provided by 
the runtime engine) can correct the problem. If the outcome of 
the test at step 54 is positive, the routine continues at step 56 
and the problem is rectified. At step 58, information about the 
problem and the corrective action that as undertaken are 
reported back to the dispatch mechanism and stored in the 
database for future use. 

This disclosure does not disclose that "the network management module monitois 
transmissions that are received from the recovery modules to provide periodic monitoring of 
the status of each of the network nodes," as recited in claim 1 . 

fii pertinent part col. 7, line 58 - col. 8, fine 9, discloses that a test is done and the 
outcome of that test indicates whether or not the software agent has arrived at the fault 
location. Turek does not provide any details about which component performs the test that is 
"done" at step 50 of FIG. 4, nor does Turek reveal anything about the type of information that 
is input into the test nor the nature of the outcome of the test that indicates whether or not the 
software agent has arranged at the fault location. Without such details there is no basis on 
which one skiUed in the art reasonably could conclude that Turek's dispatch mechanism 
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monitors transmissions that are received from the software agent to provide periodic 
monitoring of the status of the network nodes. For example, one reasonably could imagine 
an embodiment in which the software agent transmits to the display agent a message that 
indicates whether or not the software agent has arrived at the targeted fault location. Such a 
message reveals the status of the software agent, not the node. 

Moreover, claim 1 redtes "the network management module monitors transmissions 
that are received from the recovery modules to provide periodic monitoring of the status of 
each of t he network nodes" (emphasis added). In accordance with Turek's disclosure, the 
dispatch mechanism 15 deploys the software agents only after a network feult already has 
been determined by the management server 14 (see, e.g., col. 7, hnes 34) or after receiving a 
"request for maintenance in some non-specified area of the network" (col. 7, line 7), and the 
dispatched agents cease migrating after reaching their respective target nodes. Thus, a 
particular node can be expected to be visited only once by the software agents that are 
deployed by the dispatch mechanism. Accordingly, such a deployment of software agents 
could not possibly provide periodic monitoring of the status of each of the network nodes. 

For the reasons explained above, the cited sections of Turek's disclosure do not 
support the Examiner's assertion that Turek discloses "the network management module 
monitors transmissions that are received from the recovery modules to provide periodic 
monitoring of the status of each of the network nodes," as recited in claim 1 

hi. Conclusion 

As explained above, Turek's system does not launch migratory recovery modules into 
a network to monitor status of each of the network nodes, wherein the recovery modules 
determine the status of each of the network nodes and the network management module 
monitors transmissions that are received from the recovery modules to provide periodic 
monitoring of each of the network nodes, as recited in claim 1 . 

For at least these reasons, the rejection of independent claim 1 under 35 U.S.C. § 
102(e) over Turek should be withdrawn. 
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3. Claiins24,6-9. 21-25. and 30 



Each of claims 24, 6-9, 21-25, and 30 incorporates the features of independent claim 
1 and therefore is patentable over Turek for at least the same reasons explained above. 



4. Independent claim 1 1 



Independent claim 1 1 recites: 

11. A method for managing a plurality of distributed nodes 
of a network, comprising: 

(a) on a current one of the network nodes, determining a status 
of the current network node; 

(b) in response to a determination that the current network has 
one or more failed node processes, initiating a recovery process 
on the current network node; 

(c) after initiating the recovery process, migrating from the 
current network node to a successive one of the network nodes; 
and 

(d) repeating (a), (b), and (c) with the current network node 
corresponding to the successive network node for each of the 
nodes in the network. 

In support of the rejection of independent claim 1 1, the Examiner has stated that (see 
§ 19 on page 8 of the OfEice action dated February 5, 2009; emphasis added): 

As per claims 1, 11, 19 & 20 Turek-Sreenivasan [sic] disclosed 
a method for managing a plurality of distributed nodes of a 
network, comprising: a network management module that 
launches migratory recovery modules into the network to 
monitor status of each of the network nodes; wherein each of 
the recovery modules is configured to migrate from one 
network to another, determine a respective status of each of the 
network nodes to which it has migrated, and initiate a recovery 
process on failed ones of the network nodes, (col. 3, lines 48-64, 
col.l, lines 59-62, 65-67, col.2, hnes 22-26, col.2, hnes 1-3, 
col. 2, lines 22-26 & col. 5, hnes 32-60), having one or more 
failed node processes, the recovery modules determine the 
status of each of the network nodes, and the network 
management module monitors transmissions that are received 
from the recovery modules to provide periodic monitoring of 
the status of the network nodes (col.7, hnes 58-67 & col.8, lines 
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1-9 ) after initiating the recovery process, migrating from the 
current node to a successive one of the network node (col. 5, 
Unes 32-60, col.7. Unes 58-67 & col.8, lines 1-651 and the 
network management module monitors transmissions that are 
received from the recovery modules to provide periodic 
monitoring of the status of each of the network nodes (col.7, 
hnes 58-67, col. 8, lines 1-9 & col.8, lines 39-58). 

Contrary to the Examiner's assertion, however, Turek's software agents do not 
perform, any of elements (c) and (d) of independent claim 11. 

In accordance with Turek's teachings, the mobile software agents do not migrate from 
a current network node to a successive one of the network nodes after initiating a recovery 
process on the current network node. Instead, after initiating a recovery process, Turek's 
mobile software agents merely report the problem and the corrective action that was taken to 
the dispatch mechanism 15 (see col. 8, lines 6-9; FIG. 4). Turek does not teach or suggest 
anything that that would have led one skilled in the art at the time the invention was made to 
believe that the software agent migrates to any other nodes after attempting to "effect repairs" 
and reporting back with the diagnosis. Indeed, in accordance with Turek' s teachings, each of 
the mobile software agents is deployed to diagnose and, if possible, correct only one 
particular network fault. Therefore, there is no apparent need for any of Turek's software 
agents to migrate from the node that contains the particular network fault that the software 
agent was deployed to diagnose and correct. 

Thus, Turek does not disclose either element (c) or element (d) of claim 1 1 . For at 
least this reason, the Examiner's rejection of independent claim 1 1 under 35 U.S.C. § 102(e) 
over Turek should be withdrawn. 

In the Office action dated March 20, 2008, the Examiner had stated that (see §32 on 
pages 13-14; original emphasis): 



As to applicant argument with respect to claim language "after 
initiating the recovery process, migrating from the current 
network node to a successive node" in claims 1 1 & 20. The 
examiner gave 1 12 fii^t paragraph rejection on August 25-2006 
for lack of indication in the applicant's specification regarding 
this hmitation "after initiating the recovery process, migrating 
from the current network node to a successive node". 
Applicant's response onDecember-1-2006 was "It is well- 
settled, however, that the specification need not contain a literal 
transcription of the claim language defining the invention in 
order to satisfy the written description requirement. Instead, the 
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application need only reasonably convey the claimed subject 
matter to a person in the ordinary skih in the art. In accordance 
withMPEP2164.II.A.3(b). 

Therefore Examiner is applying the same rationale that the 
disclosure of the apphedreferencefs) need not contain a hteral 
transcription of the claim language defining the invention. 
Instead, the reference(s) need only reasonably convey the 
claimed subject matter to a person in the ordinary sldU in the 



hi the Appeal Briefs dated June 17, 2008 and December 18, 2008, Appellant 
explained that the Examiner's statement quoted above does not address in any way 
appellant's point that Turek' s mobile software agents do not migrate from a current network 
node to a successive one of the network nodes after initiating a recovery process on the 
current network node. Instead, after initiating a recovery process, Turek' s mobile software 
agents merely report the problem and the corrective action that was taken to the dispatch 
mechanism 15 (see col. 8, lines 6-9; FIG. 4). Furthermore, there is no apparent need for 
Turek' s software agents to migrate from the node that contains the particular network fault 
that the software agent was deployed to diagnose and correct because each of the mobile 
software agents is deployed to diagnose and, if possible correct, only one particular network 
fault (see, e.g., col. 5, hues 43-60, and col. 7, Hne 58 - col. 8, line 17). 

This point has been made repeatedly by the Appellant, yet inexplicably the Examiner 
consistently has failed to address it. Indeed, the Examiner has not even attempted to reply to 
Apphcant' s point in the Response to Arguments section of the Office action dated February 
5, 2009. 

5. Claims 12-14 and 16-19 

Each of claims 12-14 and 16-19 incorporates the features of independent claim. 11 and 
therefore is patentable over Turek for at least the same reasons explained above. 

6. Independent claim 20 



art. 



Claim 20 has been amended and now recites: 
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20. A computer-readable medium comprising a computer 
program for managing a plurality of distributed nodes of a 
network, the computer program comprising computer-readable 
instructions that, when executed by respective processors, 
cause the respective processors to perform a method 
comprisiiig: 

migrating the computer program from one network 
node to a series of successive network nodes; 

determining a status of a current one of the network 
nodes to which the computer program has migrated; 

in response to a determination that the current network 
has one or more failed node processes, initiating a recovery 
process on the current network node; and 

after initiating the recovery process on the current 
network node, migrating from the current network node to a 
successive one of the network nodes. 

Claim 20 is patentable over Turek in view of Sreenivasan for at least the same reasons 
explained above in connection with independent claim 11. Accordingly, the Examiner's 
rejection of independent claim 20 under 35 U.S. C. § 102(e) over Turek should be withdrawn. 

B. Rejection of claims 5 and 15 under 35 U.S.C. § 103(a) over Turelt in view 



The Examiner has rejected claims 5 and 15 under 35 U.S.C. § 103(a) over Turek in 
view of Sreenivasan (U.S. 2002/0049845). 

1. Apphcable standards for sustaining a rejection under 35 U.S.C. § 103(a) 

"A patent may not be obtained ... if the differences between the subject matter sought 
to be patented and the prior ait are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to 
which said subject matter pertains." 35 U.S.C. §103(a). 

In an appeal involving a rejection under 35U.S.C. §103, an examiner bears the initial 
burden of establishing prima facie obviousness. See In re Rijckaert , 9 F.3d 1531, 1532, 28 
USPQ2d 1955, 1956 (Fed. Cir. 1993). To support a prima facie conclusion of obviousness. 



of Sreenivasan 
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the prior ait must disclose or suggest all the limitations of the claimed invention. 1 See In re 
Lowiy. 32F.3d 1579, 1582, 32USPQ2d 1 031, 1034 (Fed. Cir. 1994). If the examiner has 
established a prima facie case of obviousness, the burden of going forward then shifts to the 
appHcant to overcome the primafacie case with argument and/or evidence. Obviousness, is 
then determined on the basis of the evidence as a whole and the relative pei^uasiveness of the 
arguments. This inquiry requires (a) determining the scope and contents of the prior art; (b) 
ascertaining the differences between the prior ait and the claims in issue; (c) resolving the 
level of ordinary skUl in the pertinent art; and (d) evaluating evidence of secondary 
consideration. See KSR Int'l Co. v. Teleflex hic . No. 127 S. Ct. 1727, 1728 (2007) (citing 
Graham V. JohnPeere. 383 U.S. I 17-18, 148 USPQ 459, 467 (1966)). If all claim 
limitations are found in a number of prior art references, the fact finder must determine 
whether there was an apparent reason to combine the known elements in the fashion claimed. 
See KSR. 1741. This analysis should be made exphcit. KSR at 1741 (citing hi re Kahn. 441 
F. 3d 977, 988 (Fed. Cir. 2006): "[RJejections on obviousness grounds cannot be sustained 
by mere conclusory statements; instead, there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness"). 

2. Independent claim 5 

a. Introduction 

Independent claim 5 has been amended and now recites: 



1 The U.S. Patent and Trademark Office has set forth the following definition of the 
requirements for estabhshing a prima facie case of unpatentability (37 CFR § 1.56(b)(ii)): 



A prima fecie case of unpatentabihty is established when the 
information compels a conclusion that a claim is unpatentable 
under the preponderance of evidence, burden- of-proof standard, 
giving each term in the claim its broadest reasonable 
construction consistent with the specification, and before any 
consideration is given to evidence which may be submitted in 
an attempt to estabhsh a contiary conclusion of patentabihty. 



5 . A system for managing a plm^ty of distiibuted 
nodes of a network, comprising: 

first and second ones of the network nodes; 



wherein 
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the first network node is operable to execute a recovery 
module that causes the first network node to migrate the 
recovery module &om the first network node to the second 
network node, and 



in response to receipt of the recovery module 

from the first network node, the recovery 
module causes the second network node 
to determine a status of the second 
network node in accordance with a 
heartbeat messaging protocol, and 

in response to a determination that the second 
network node has one or more MLed 
processes, the recovery module causes 
the second network node to initiate a 
recovery process on the second network 
node. 



As explained in detail below, the rejection of independent claim 5 under 35 U.S.C. § 
103(a) over Turek in view of Sreenivasan should be withdrawn because (1 ) the Examiner has 
not shown that the cited references disclose each and every element of the claim, and (2) one 
skilled in the ait at the time the invention was made would not have had any apparent reason 
to modify the teachings of Turek in the manner proposed by the Examiner. 

b. The Examiner' s position 

In support of the rejection of claim 5, the Examiner has stated that (see § 15, page 6 of 
the Office action dated February 5, 2009; emphasis added): 



As per claims 5 Turek disclosed a system for managing a 
plurahty of distributed nodes of a network, comprising: a 
recovery modules configured to migrate from one network 
node to another, determine a status of a network, and initiate a 
recovery process on a network node having one or more Mled 
node processes (col.2, fines 6567 & col.2, fines 1^6) wherein 
the recovery module is configured to determine the status of a 
network node in accordance with a heartbeat mess^ing 
protocol (col.2, fines 22-46). Although Turek disclosed 
software agent (module) providing network status information 
to the management module. However Turek did not specifically 
mentioned agent using a "heartbeat messaging protocol" to 
determine the status of a network node. In the same field of 
endeavor Sreenivasan disclosed daemon (module or software 
agent) sending "I am alive message" (heartbeat messaging 
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protocol') to determine the status of a network node (paraaraphs 
78, 111 & 112). 



It would have been obvious to one in the ordinary sldll in the 
art at the time the invention was made to have incorporated the 
functionality of daemon (module or software agent) sending "I 
am ahve message" (heartbeat messaging protocol) to determine 
the status of a network node as disclosed by Sreenivasan in the 
a system for managing a plurahty of distributed nodes of a 
network as disclosed by Turek in order to make the managing 
system more reliable and responsive resulting in determining 
accurate diagnosis and status of the network nodes. 

c. Appellant's rebuttal: the died references do not disclose each and every 
element of claim 5 

Claim 5 recites that "the recovery module causes the second network node to 
determine a status of the second network node in accordance with a heartbeat messaging 
protocol." Thus, under a proper construction of claim 5, the term "status" must be construed 
as a status of the network node that is determinable in accordance with a heartbeat messaging 
protocol. 

Heartbeat messaging is a well-known feature of networks in accordance with which a 
"heartbeat" message is sent regularly from one node to another node merely to detect failed 
apphcations or failed nodes (see, e.g., Forbes, U.S. 6,728,896, col. 4, hnes 27-33, and col. 9, 
lines 2-14; cited by the Examiner). Such heartbeat messages indicate the statement "I'm 
here, are you here?" (see, e.g., col. 9, hnes 2-14, of Forbes, U.S. 6,728,896; cited by the 
Examiner). 

As explained above, Turek does not disclose or suggest a recovery module that is 
configured to determine the status of a network node in accordance with a heartbeat 
messaging protocol. Instead, Turek discloses that network errors or feults are determined by 
the remote management server 14 (see, e.g., col. 5, hnes 3 1-60). When a network error or 
fault is determined, the management node 14 deploys the mobile software agents to diagnose 
and, if possible, correct the network error or feult (see, e.g., col. 5, hnes 3742). Given the 
limited information provided by heartbeat messages, they cannot be used to "diagnose and, if 
possible, correct a network fault" as required of the mobile software agents (see Turek, col. 5, 
lines 41-42). Instead, the mobile software agents perform these tasks by performing tests at 
the nodes to which the software agents were deployed by the management server 14 (see col. 
7, line 58 - col. 8, Hne 9). Thus, Turek fails to disclose or suggest software agents that 
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detemiitie the "status" of a network node, where the "status" is determinable in accordance 
with a heartbeat messaging protocol. 

Contrary to the Examiner's position, however, Sreenivasan does not disclose anything 
about recovery modules of the type disclosed in Turek, much less anything about such 
modules that "cause the second network node to determine a status of the second network 
node in accordance with a heartbeat messaging protocol." 

In paragraph 78, Sreenivasan discloses (emphasis added): 



hi the embodiment shown in FIG. 1, the two server systems 12 
are connected to both apubhc network 14 and a private 
network 18. Clients 16 use pubHc network 14 to access services 
from the cluster. Software running on each server 12 use 
private network 18 to exchange heartbeat and other control 
messages. In one embodiment, private network 12 comprises a 
serial communication network with a serial multiplexor 20 
intercoimecting the server nodes 12 to the private network 18. 
hi the event of a server or apphcation failure, the surviving 
system 12, if appropriately configured, assumes the public 
network address of the failed system 12 and answer requests 
from chents 16 on network 14. In one embodiment, chents 16 
perceive the failover process as a rapid reboot of the failed 
primary server. 



Thus, ]f 78 of Sreenivasan does not disclose or suggest that recovery modules of the type 
disclosed in Turek are configured to determine the status of a network node in accordance 
with a heartbeat messaging protocol as assumed incorrectly by the Examiner. Instead, Tf 78 
discloses in pertinent part that " Software running on each server 12 use private network 18 to 
exchange heartbeat and other control messages." 

Paragraphs 111 and 1 12 of Sreenivasan read as follows: 



As noted above, the main component of the Cluster 
Membership Service is the Cluster Membership Daemon. In 
some embodiments, the Cluster Membership Daemon is 
responsible for running the whole protocol and is represented 
by the Membership Daemon that runs on it. The daemon 
maintains in an internal variable its current view of the 
Membership. The daemon is said to have dehvered a new 
Membership when the value of that variable is changed. 

Each CMD sends messages to other CMD's by invoking a 
broadcast primitive. The desrinarion of the broadcast are all the 
nodes in S except the originator. Typically, the broadcast 
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primitive is the only way CMD sends messages. The semantic 
of the broadcast primitive are very weak. Message can be lost 
and there are httle guarantees on the ordering at the receive 
end. Current implementation of the daemon uses UDP/IP, 
however any datagram transport can be substituted. The 
broadcast primitive prepends a header to the message. As stated 
above CMD uses one type of message. Each message contains 
useful information and at the same time can be considered as an 
"I'm alive message" from the sender. CMD is required to 
periodically broadcast a message. The interval between 
broadcasts is a configurable parameter. 



Thus, neither Tf 1 1 1 nor 1 1 12 of Sreenivasan teaches that recovery modules of the 
type disclosed in Turek are configured to determine the status of a network node in 
accordance with a heartbeat messaging protocol. Instead, the CMD processes nmning on 
each of the servers in the cluster communicate with each other to detect server failure. In 
particular, Sreenivasan teaches that each server 12 in the cluster runs Cluster Management 
Services (CMS) 32 and Group Communication Services (GCS) 34 (see Tf 79), where an 
instance of the CMS service 12 is referred to as a Cluster Management Daemon (CMD) (see 
Tf 85). Nodes are represented by the CMD processes that run on them and the Mlure of such 
a CMD is interpreted as the Mlure of the node (see Tf 85). The CMD processes runiitng on 
the servers 12 communicate using a Cluster Management Protocol 36 that includes an 
initialization phase, a monitoring phase, and an agreement phase (see THj 85-88). During the 
monitoring phase, the nodes in the cluster send and receive heartbeat mess^es (see T| 89). 
Paragraphs 1 1 1 and 1 12 explain some of the details of the communications between the CMS 
processes running on the network nodes. 

To summarize, the Examiner has taken the position that the CMD processes running 
on the servers of the Sreenivasan' s cluster constitute "recovery modules." These CMD 
processes, however, are not mobile. Moreover, the CMD processes do not a network node to 
determine a status of itself in accordance with a heartbeat messaging protocol; instead, the 
CMD processes transmit heartbeat messages between different nodes. 

Therefore, both Turek and Sreenivasan Ml to disclose or suggest software agents that 
determine the "status" of a network node, where the "status" is determinable in accordance 
with a heartbeat messaging protocol. Since the cited references do not disclose or suggest 
disclose or suggest all the limitations of the invention defined in claim 5, the rej ection under 
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35 U.S.C. § 103(a) over Turek in view of Sreeiiivasan should be withdrawn. See In re 
Lowry. 32F.3d 1579, 1582, 32USPQ2d 1 031, 1034 (Fed. Cir. 1994). 

d. Appellant's rebuttal: the rationale given in support of the combiiiation of 
Turek and Sreenivasan does not establish a prima facie case of obviousness 

The rationale given by the Examiner in support of his proposed combination of Turek 
and Sreenivasan does not estabHsh a prima facie case of obviousness. In particular, the 
Examiner' s position is that it would have been obvious "to have incorporated the 
functionality of daemon (module or software agent) sending "1 am ahve message" (heartbeat 
messaging protocol) to determine the status of a network node as disclosed by Sreenivasan in 
the a system for managing a plurality of distributed nodes of a network as disclosed by 
Turek." hi accordance with Turek' s teachings, however, the management server 14 
determines network errors or faults (see, e.g., col. 5, lines 31-60) and subsequently deploys 
the mobile software agents to diagnose and, if possible, correct the network error or fault 
(see, e.g., col. 5, Hnes 37^2). The incorporation of a heartbeat messaging protocol into the 
management server 14 to determine the status of a network node as disclosed by Sreenivasan 
(i.e., by exchanging heartbeat messages between software running on each server) would not 
result in the invention defined in claim 5, where "the recovery module is configured to 
determine the status of a network node in accordance with a heartbeat mess^ing protocol." 

For at least this additional reason, the rejection of claim 5 under 35 U.S.C. § 103(a) 
over Turek and Sreenivasan should be withdrawn. 

e. Appellant's rebuttal: one skilled in the art at the time the invention was made 
would not have had any apparent reason to modify the teachings of Turek in 
the manner proposed by the Examiner 

In accordance with Turek' s teachings, the software agents are deployed only after an 
event, such as a network fault, has been determined by the management server 14 (see, e.g., 
col. 2, hnes 35-37). Therefore, there is no need for the software agents to use a heartbeat 
messaging protocol to determine whether such an event originated from a particular node. 
Instead, each software agent need only be tailored to specifically identify the particular 
network feult that triggered the deployment of the software agent by the management server 
14 (see, e.g., col. 5, lines 31-60 and col. 6, hnes 23-59). As explained above, such 
information is not determinable in accordance with a heartbeat protocol due to the hmited 
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nature of the information conveyed by the heartbeat messages (i.e., "I'm here, are you here?") 
For at least this reason, one sMlled in the art at the time the invention was made would not 
have had any apparent reason to modify the teachings of Turek in the manner proposed by the 
Examiner. 

In addition, the Examiner has premised his proposed combination of Turek and 
Sreenivasan on the following rationale: 



It would have been obvious to one in the ordinary sldll in the 
ait at the time the invention was made to have incorporated the 
ftmctionahty of daemon (module or software agent) sending "I 
am alive message" (heartbeat messaging protocol) to determine 
the status of a network node as disclosed by Sreenivasan in the 
a system for managing a plurahty of distributed nodes of a 
network as disclosed by Turek in order to make the managing 
system more reliable and responsive resulting in determining 
accurate diagnosis and status of the network nodes. 



Neither Turek nor Sreenivasan, however, provides any support for the Examiner's 
assertion that modifying his proposed modification of Turek' s system would "make the 
managing system more rehable and responsive resulting in determining accurate diagnosis 
and status of the network nodes." This assertion is a pure fabrication of the Examiner' s 
imagination. 

Moreover, there is nothing in the disclosure of either Turek or Sreenivasan that would 
have led one skilled in the art at the time the invention was made to modify Turek' s 
migratory software agents to run the seiver-node-based CMD processes (i.e., the instances of 
the Cluster Management Services (CMS) 32; see Tf 85) that are disclosed in Sreenivasan. For 
example, each of the CMDs is designed to run on a single server of a cluster (see, e.g., Tf 85). 
Neither Turek nor Sreenivasan nor the knowledge generally available even hints that such 
CMD processes could be incorporated into migratory software agents for the purpose of 
diagnosing and correcting erroi^ or faults on the nodes to which the agents are deployed (see, 
e.g., col. 5, lines 41-47). 

Even assuming only for the purposes of argument that Turek' s migratory agents could 
be modified to run the CMD processes, one skilled in the art would not have had a reasonable 
basis for beheving that the CMD framework would work when running on migratory 
software agents of the type described in Turek. In particular, the CMD framework is 
designed to operate with each of the CMDs running on a single respective server of a cluster. 
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Neither Turek nor Sreenivasan provides any basis for believing that the CMD framework 
could work for its intended purpose if the CMDs were somehow able to migrate from one 
server to another as proposed by the Examiner. 

In addition, instead of pointing to some teaching or suggestion in Turek, Sreenivasan, 
or the knowledge generally available to support the proposed combination of Turek and 
HarveU, the Examiner has rehed on cfrcular reasoning. In particular, the Examiner's 
proffered motivation (i.e., because it would " . . .make the managing system more reliable and 
responsive resulting in determining accurate diagnosis and status of the network nodes") 
assumes the result (i.e., the modification of Turek' s system) to which the proffered 
"motivation" was supposed to have led one sMlled in the art. Such circular reasoning cannot 
possibly support a rejection under 35 U.S.C. § 103(a). Indeed, such circular reasoning only 
evidences the feet that the Examiner improperly has engaged in impermissible hindsight 
reconstruction of the claimed invention, using apphcants' disclosure as a blueprint for piecing 
together elements from the prior art in a manner that attempts to reconstruct the invention 
recited in claim 1 only with the benefit of impermissible hindsight (see KSR Int'l Co. v. 
Tele flex Inc., slip op. at 17: "A factfinder should be aware, of course, of the distortion caused 
by hindsight bias and must be cautious of arguments rehant upon ex post reasoning."). The 
fact is that neither Turek nor Sreenivasan nor the knowledge generally available at the time 
the invention was made would have led one skilled in the art to beheve that there was any 
problem to be solved or any advantage that would be gained by the Examiner' s proposed 
modification of Turek' s system. 

Without any apparent reason for modifying Turek' s system, the Examiner's rationale 
in support of the rejection of claim 5 amounts to no more than a conclusory statement that 
cannot support a rejection under 35 U.S.C. § 103. 

Thus, contiary to the Examiner's position, one skilled in the art at the time the 
invention was made would not have been led to modify Turek's migratory software agents to 
run the CMD processes (i.e., the instances of the Cluster Management Services (CMS) 32; 
see 1 85) disclosed in Sreenivasan. 

For at least these additional reasons, the rejection of claim 5 under 35 U.S.C. § 103(a) 
over Turek in view of Sreenivasan should be withdrawn. 
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f Conclusion 

For the reasons explained above, the rejection of claim 5 under 35 U.S. C. § 103(a) 
over Turek in view of Sreenivasan should be withdrawn. 

3. Dependent claim 15 

Claim 15 depends from independent claim 1 1 and recites that "the status of a network 
node is determined in accordance with a heartbeat messaging protocol." 

Sreenivasan does not make-up for the feilure of Turek to disclose or suggest the 
elements of independent claim 1 1 discussed above. Indeed, Sreenivasan does not disclose 
anything about recovery modules of the type disclosed in Turek, much less anything about 
such modules that are "configured to determine the status of a network node in accordance 
with a heartbeat messaging protocol." Moreover, one sMlled in the art at the time the 
invention was made would not have had any apparent reason to combine Turek and 
Sreenivasan in the manner proposed by the Examiner for the reasons explained above in 
connection with independent claim 5 . 

For at least these reasons, the rejection of claim 15 under 35 U.S.C. § 103(a) over 
Turek in view of Sreenivasan should be withdrawn. 

C. Rejection of claims 27-29 under 35 U.S.C. § 103(a) over Turek in view of 



The Examiner has rejected claims 27-29 under 35 U.S.C. § 103(a) over Turek in view 
ofDouik (U.S. 6,012,152). 

Each of claims 27-29 incorporates the features of independent claim 1. Douik does 
not make-up for the failure of Turek to teach or suggest the features of independent claim 1 
discussed above. Therefore, claims 27-29 are patentable over Turek and Douik for at least 
the same reasons explained above in connection with independent claim 1 . 

Claims 27-29 also are patentable over Turek in view of Douik for at the following 
additional reasons. 



Douik 
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Claim 27 redtes that the network management module causes the processor to 
determine a number of the recovery modules needed to achieve a specified network 
monitoring service level, and to launch the determined number of recovery modules into the 
network to achieve the specified network monitoring service level. 

In support of the rejection of claim 27, the Examiner has stated that (see § 3 1 on pages 
11-12 of the Office action dated Febniary 5, 2009; emphasis added): 

... Turek did not explicitly disclose, wherein the network 
management module statistically identifies target ones of the 
network nodes to achieve a specified confidence level of 
network monitoring rehabihty, and proactively laimches the 
recovery modules into the network by tiansmitting respective 
ones of the recovery modules to the identified target network 
nodes. In the same field of endeavor Douik disclosed wherein 
the network management module statisticahy identifies target 
ones of the network nodes to achieve a specified confidence 
level of network monitoring rehabifitv. and launches the 
recovery modules into the network by tiansmitting respective 
ones of the recovery modules to the identified target network 
nodes (col. 1 1, fines 64-67 & col. 12, fines 1-19). 

As pointed out in the Amendment dated November 27, 2006 (see § IV.G. 1 on pages 
19-20), and agaminthe Response dated May 7, 2007 (see § Ill.C.l on pages 25-26), and 
again in the Appeal Brief dated December 18, 2008 (see § VIl.C.l on pages 29 et seq), 
contiary to the Examiner's assumption, claim 27 does not recite that the network 
management module "identifies target ones of the network nodes to achieve a specified 
confidence level of network moiutoring refiability, and laimches the recovery modules into 
the network by tiansmitting respective ones of the recovery modules to the identified target 
network nodes." Instead, claim 27 recites that "the network management module determines 
a number of the recovery modules needed to achieve a specified network monitoring service 
level, and laimches the determined number of recovery modules into the network to achieve 
the specified network monitoring service level." Thus, on its face, the Examiner's rejection 
of claim 27 does not estabfish a prima facie case of obviousness (see MPEP § 706.02(j)). 

Moreover, Doiuk does not teach or suggest anything about migratory recovery 
modules, much less anything about determining a number of the recovery modules needed to 
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achieve a specified network momtoring service level and launching the determined number of 
recovery modules into the network to achieve the specified network monitoring service level. 

The disclosure on which the Examiner's rejection of claim 27 is premised reads as 
foUows (i.e., col. 11, hne 64 - col. 12, line 19): 



In yet another aspect, the present invention is a method of 
proactively managing software feults in a mobile 
telecommunications network. The method begins by storing 
knowledge in a knowledge base, the knowledge including a 
functional model of the network, feult models, and feult 
scenarios; momtoring the network for observed events and 
symptoms; and determining a suspected feult to explain the 
observed events and symptoms, the determining step 
comprising comparing the observed events and symptoms with 
stored performance data and statistics, and analyzing the 
comparison with the stored knowledge. This is followed by 
determining whether the suspected fault is a known fault; 
implementing a preventive solution upon determining that the 
suspected feult is a known feult; and performing a fault tiend 
analysis upon determining that the suspected feult is not a 
known feult. This is followed by performing diagnostic tests; 
determining whether a successfiil diagnosis was obtained; 
performing a feult locafization process upon determining that a 
successful diagnosis was obtained, the feult localization process 
including analyzing relationships between components 
involved in the diagnosis of the fault; and providing diagnosis 
and localization information to trouble shooters. 



This disclosure does not describe anything whatsoever about migratory recovery modules, 
much less anything about determining a number of the recovery modules needed to achieve a 
specified network monitoring service level and launching the determined number of recovery 
modules into the network to achieve the specified network monitoring service level. 

For at least these additional reasons, the Examiner's rejection of claim 27 under 35 
U . S .C . § 1 03 (a) over Turek in view of Domk should be withdrawn. 

2. Claim 28 



Claim 28 redtes that the network management module causes the processor to 
statistically identify target ones of the network nodes that are needed to achieve a specified 
confidence level of network moiutoring rehabifity, and the network management module 
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causes the processor to launch the recovery modules into the network by transmitting 
respective ones of the recovery modules to the identified target network nodes. 

In support of the rejection of claim 28, the Examiner has stated that (see § 3 1 on pages 
11-12 of the Office action dated Febniary 5, 2009; emphasis added): 

... Turek did not expHcitly disclose, wherein the network 
management module statistically identifies target ones of the 
network nodes to achieve a specified confidence level of 
network monitoring rehahUity, and proactively laimches the 
recovery modules into the network by transmitting respective 
ones of the recovery modules to the identified target network 
nodes. In the same field of endeavor Douik disclosed wherein 
the network management module stadsticalLv identifies target 
ones of the network nodes to achieve a specified confidence 
level of network monitoring rehabihty. and launches the 
recovery modules into the network by transmitting respective 
ones of the recovery modules to the identified target network 
nodes (col. 1 1, fines 64-67 & col. 12, fines 1-19). 

The disclosure on which the Examiner's rejection of claim 28 is premised reads as 
foUows (i.e., col. 11, fine 64 - col. 12, line 19): 



hi yet another aspect, the present invention is a method of 
proactively managing software feults in a mobile 
telecommunications network. The method begins by storing 
knowledge in a knowledge base, the knowledge including a 
fimctional model of the network, feult models, and feult 
scenarios; monitoring the network for observed events and 
symptoms; and determining a suspected feult to explain the 
observed events and symptoms, the determining step 
comprising comparing the observed events and symptoms with 
stored performance data and statistics, and analyzing the 
comparison with the stored knowledge. This is followed by 
determining whether the suspected fault is a known fault; 
implementing a preventive solution upon determining that the 
suspected feult is a known feult; and performing a fault trend 
analysis upon determining that the suspected feult is not a 
known feult. This is followed by perfortning diagnostic tests; 
determining whether a successftil diagnosis was obtained; 
performing a feult locafization process upon determining that a 
successful diagnosis was obtained, the feult localization process 
including analyzing relationships between components 
involved in the diagnosis of the fault; and providing diagnosis 
and localization information to trouble shooters. 
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In this disclosure, Domk merely compares observed events to stored performance data and 
statistics in order to determine a suspected fault to explain the observed events and 
symptoms. Douik does not even hint that taiget nodes are identified statistically to achieve a 
specified confidence level of network monitoring reliability. Moreover, Douik does not teach 
or suggest anything about migratory recovery modules and launching the recovery modules 
into the network by transmitting respective ones of the recovery modules to the identified 
target network nodes. 

For at least this additional reason, the Examiner's rejection of claim 28 under 35 
U . S .C . § 1 03 (a) over Turek in view of Domk should be withdrawn. 

3. Claim 29 

Claim 29 depends fi:om claim 1 1 and recites: determining a number of the recovery 
modules needed to achieve a specified network monitoring service level; statistically 
identifying target ones of the network nodes to achieve a specified confidence level of 
network monitoring reliabihty, and transmitdng the determined number of the recovery 
modules to the identified target network nodes. 

Claim 29 redtes features that essentially track the pertinent features of claim 28 
discussed above. Therefore, claim 29 is patentable over Turek in view of Douik for at least 
the same reasons explained above in connection with claim 28. 

V. Conclusion 



For the reasons explained above, aU of the pending claims are now in condition for 
allowance and should be allowed. 

Charge any excess fees or apply any credits to Deposit Account No. 08-2025. 
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Respectfully submitted. 
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